ADFA-6373 | Support Gradle task arguments and expose visible terminal sessions - #2110

F01 (High): build output appears twice in the Build Output pane. The tooling server already streams this build into the pane. Here the pane is read back (getBuildOutput()) and every line goes out as StdOut, and PluginBuildActionItem.execAction (line 126) calls activity.appendBuildOutput(line) for each one. So a plugin build action whose spec is CommandSpec.GradleTask prints the whole log (up to 128K chars) a second time, followed by Process failed with code 1 on failure.

MINOR: Still open at 822d366e3. GradleTaskExecution.kt:91-93 still re-emits getBuildOutput() as StdOut, and PluginBuildActionItem.kt:117-126 appends each line to the pane the tooling server already streamed into, so the log appears twice.

MINOR on reachability: a CommandSpec.GradleTask build action comes only from code or a manifest gradle_task entry, and no plugin in plugin-examples main or addons declares one today. Direct executeCommand callers are unaffected; they want the StdOut lines.

Fix: in PluginBuildActionItem, skip appending output for GradleTask specs, since the pane already has it.

F02 (High): plugin-controlled Gradle arguments skip the SYSTEM_COMMANDS permission. IdeBuildService is registered for every plugin without a permission check (PluginManager.kt ~1445 and ~1718). executeTasks(listOf("help"), listOf("--init-script", "/path/evil.gradle")) runs arbitrary Groovy in the IDE's Gradle daemon. Task names are now passed as command-line arguments too, so the old vararg executeTasks("-I", "/path/evil.gradle") does the same. cancelBuild() has no check either, so any plugin can kill the user's build.

IMPORTANT: Still open at 822d366e3. IdeBuildService is registered for every plugin with no permission (PluginManager.kt:1445 and :1718), and executeTasks(tasks, arguments) passes arguments straight into GradleBuildParams. A plugin without SYSTEM_COMMANDS can call executeTasks(listOf("help"), listOf("--init-script", path)) and run Groovy in the IDE's Gradle daemon. Tasks now go through addArguments too, so the vararg executeTasks("-I", path) does the same, and cancelBuild() is ungated. The same capability through CommandSpec.GradleTask does require SYSTEM_COMMANDS (IdeCommandServiceImpl.kt:40), so the permission now depends on which door a plugin uses.

Fix: register IdeBuildService per plugin with its permissions, require SYSTEM_COMMANDS for non-empty arguments and for cancelBuild(), and reject task names starting with -.

F04 (Medium): a plugin GradleTask holds the IDE's single build slot for up to its timeout (600 s by default). A project sync started while it runs is refused. 465873e at least passes the reason (BUILD_IN_PROGRESS) to postProjectInit now, but the user still can't sync until the plugin's task ends or times out. The old ./gradlew path never touched the slot. Should a sync take priority, or should plugin tasks use a shorter default timeout?

MINOR: Unchanged at 822d366e3. A plugin GradleTask still holds the only build slot for its whole run, up to the 600 s default timeout (BuildActionExtension.kt:69), and a sync or user build started meanwhile is refused. That follows from running on the tooling server, so it needs a decision rather than a code fix: a shorter default for plugin tasks, or letting a user-started sync or build cancel a plugin's task. Neither the code nor the PR description answers it yet.

F05 (Medium): the timeout is only a request. The result of cancelBuild() is thrown away. If the cancel isn't queued (wasEnqueued=false) or Gradle ignores it, nothing else enforces timeoutMs and await() hangs. The old path killed the process. Also, cancel() (or plugin unload) reports Cancelled straight away while the build keeps running and holding the slot, so the plugin's next task is refused.

MINOR: Still open at 822d366e3. The timeout (GradleTaskExecution.kt:52-55) discards cancelBuild()'s result, so if the cancel is not enqueued nothing completes the command and await() waits on Gradle. cancel() (lines 109-116) completes Cancelled at once while the build keeps the slot until Gradle stops, so a plugin that cancels and immediately starts another task gets Refused("another build is in progress").

MINOR because a running build normally does enqueue the cancel; the refusal after cancel is the reachable part, and it is accurate if confusing.

Fix: give the timeout a grace period after which the command completes as a timeout failure, and have cancel() complete when the build future does.

F06 (Medium): the output can be missing its last lines or come from an older build. The pane is read as soon as the build call returns, but output lines reach the pane asynchronously (posted to the main thread, or written to the session file on a later flush). whenComplete can run before BUILD FAILED or the test failure summary is appended. With no editor activity attached, prepareBuild skips clearBuildOutput, so sessionFileTail can return the previous build's log as this task's output.

MINOR: Partly open at 822d366e3. BuildOutputProvider's live read is posted to the main thread behind any output lines already queued there, so a missing tail is less likely than described. Still true: the output is the shared pane rather than this run's, cut to its last 128K characters, and with no editor attached it falls back to the session file, which can hold an earlier build's log. I could not reproduce it on a device, so MINOR.

Fix: collect this run's output from its own progress events, as GradleBuildService already does for internal builds with InternalBuildOutputCapture (GradleBuildService.kt:127).

F07 (Medium): executeTasks(vararg String) did change. executeTasks() with no tasks used to run Gradle's default tasks; now it returns false straight away ("no tasks were given"). A task string starting with - (--offline, -I x) used to be rejected as a task name; now it is applied as an option. Please document both changes, or keep the old behaviour.

MINOR: Still open at 822d366e3. The changelog still says executeTasks(vararg String) is unchanged. On stage an empty call ran Gradle's default tasks through forTasks(); now it returns false ("no tasks were given", IdeBuildServiceImpl.kt:127). A string starting with - used to be a failing task name and is now applied as an option, because tasks go into addArguments (GradleBuildExts.kt). A plugin author reading the changelog will expect neither.

Fix: document both changes under 26.41, or keep the vararg overload on forTasks.

F08 (Medium): a "visible" terminal command can run with no window. If the service binds before onStart sets mIsVisible, TermuxActivity.onServiceConnected calls finishActivityIfNotFinishing() (no sessions, not visible). Then runCommand still claims the request and creates the session in the finishing activity. The command runs in the background and the user never sees it, which breaks runInTerminal's promise of a visible session. Check isFinishing before claiming the request.

MINOR: Still open at 822d366e3. TerminalActivity.onServiceConnected calls super first, and TermuxActivity.onServiceConnected finishes the activity when there are no sessions and mIsVisible is false. runCommand (line 84) then still claims the request and starts the session in the finishing activity, so the command runs with no window. I could not confirm a real launch where the service connects before onStart, so MINOR.

Fix: check isFinishing before TerminalCommandRequests.claim and report NotStarted.

MINOR: This now says the service refuses a second build silently, but a build that loses the slot claim shows the user "Task execution failed: BUILD_IN_PROGRESS".

GradleBuildService now answers a lost claim with TaskExecutionResult(false, BUILD_IN_PROGRESS) (GradleBuildService.kt:841). BuildViewModel.kt:137, outside this diff, turns any non-cancelled failure into RuntimeException("Task execution failed: ${result?.failure}"). On stage the same race threw BuildInProgressException("A build is already running!"), which read fine. It only happens when another build claims the slot between this action's isBuildInProgress check and executeTasks, so it is rare.

Fix: map BUILD_IN_PROGRESS in BuildViewModel to the slot-busy message, as BUILD_CANCELLED is at line 132, and correct this comment.

MINOR: cancel() and the timeout stop whichever build is current, not necessarily this one.

cancelBuild() is not tied to this run's build id; the only guard is future?.isDone. If this run's slot is released and another build (the user's Run, a sync) starts before the mapped future run completes, this cancel stops that build, and its owner gets no reason. The window is short, which is why this is MINOR, but the result is someone else's build cancelled.

Fix: keep the build id this run was given and cancel only if it is still the current build.

MINOR: Unloading a plugin does not stop its runInTerminal command.

PluginManager cancels a plugin's IdeCommandService commands when it unloads or crashes (cancelAllCommands, PluginManager.kt:808 and :1196), but there is no counterpart for this service: kill is reachable only through the caller's coroutine. A plugin that calls runInTerminal from a scope it does not cancel in deactivate() leaves the command running, and TerminalCommandRequests keeps the request, with its result callback into the unloaded plugin, until the session exits. MINOR because it needs a plugin that leaks its own scope.

Fix: track the kill functions per service instance and call them from the same unload path as cancelAllCommands.

NITPICK: The exhaustive when over CommandSpec became an early return plus an unchecked cast.

With two subtypes this works. A third CommandSpec subtype would still compile and fail here with ClassCastException at runtime, where a when would have failed the build.

Fix: when (spec) { is CommandSpec.GradleTask -> ...; is CommandSpec.ShellCommand -> ... }.